home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16065 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.9 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 07:34:30 -0500
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4kdlgm$10f@solutions.solon.com>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg>
  9. Reply-To: seebs@solon.com
  10. NNTP-Posting-Host: solutions.solon.com
  11.  
  12. In article <dewar.829011320@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  13. >Peter said
  14.  
  15. >"How?  No offense meant, but any code which can be affected by this is flat
  16. >out broken.  POSIX-style read is to be given a pointer to at least nbytes
  17. >of space, for the information read.  Period."
  18.  
  19. >That's really confusing, the code in question DID give a buffer large
  20. >enough to hold nbytes of data, where nbytes is the number of bytes 
  21. >for "the information read". Maybe I don't understand, but reading the
  22. >above sentence, it sounds like you would be surprised by the Linux
  23. >behavior.
  24.  
  25. If you don't provide enough space for the number of bytes you request,
  26. you are lying to the system.  I cannot imagine a reason to do this, though
  27. I'm curious.
  28.  
  29. >Here is the exact case. We declare a buffer of 100 bytes. We read a
  30. >1000 bytes from a file whose total length is 68 bytes. On all systems
  31. >that we had experience with other than Linux, this worked fine, the
  32. >first 68 bytes of the buffer is filled, and the remaining 32 bytes
  33. >is unused. 
  34.  
  35. Why are you reading 1000 bytes if you *know* there aren't that many?
  36.  
  37. Also, how do you propose to *prove* that, between your last check, and
  38. your read, no one has added to the file?  There's no sane strategy
  39. here.
  40.  
  41. But mostly, I can't imagine any reason to do this; if you know there are
  42. no more than N bytes of data that you want, what possible reason is
  43. there to read more than N?
  44.  
  45. >I am not claiming this is "correct" code in some abstract sense. I
  46. >certainly can't tell that it is wrong from the definitions I have
  47. >of the read function. What I am claiming is that this worked on
  48. >all systems we tried it on, and then failed on Linux. I am not saying
  49. >Linux is wrong here, just that its behavior was surprising!
  50.  
  51. I'm not surprised at all; I'd not be surprised by any syscall doing bounds
  52. checking on arguments.
  53.  
  54. What's wrong is that you're lying; you are saying "here's a buffer to read
  55. 1000 bytes into, it's large enough" and it's not large enough for 1000
  56. bytes.
  57.  
  58. >The code in question made 100% sure that the data read would never
  59. >exceed the buffer size, and I would have been hard pressed to
  60. >determine that the code was incorrect. 
  61.  
  62. I'd love to know how you're sure of this in a multitasking environment.
  63.  
  64. >I am not sure that POSIX is relevant here, almost none of the systems on
  65. >which we ran claimed POSIX compliance. Peter, can you post the POSIX
  66. >wording on read, I don't have it at hand. Does it in fact make it
  67. >clear that the Linux behavior is correct and that the program was
  68. >wrong.
  69.  
  70. I don't have it at hand either; I can say that the basic statment made
  71. is that it reads at most nbytes bytes from file into the buffer.  I don't
  72. think the issue is explicitly addressed, because no one had ever tried
  73. it.
  74.  
  75. >Let's suppose that the POSIX standard does in fact make it clear that
  76. >the Linux behavior is correct. I still think the check is unwise
  77. >(note that the check is not against the actual size of the buffer
  78. >given, this is of course impossible in C, it is against the end
  79. >of the address range of the data area). It's a good example of the
  80. >kind of principle I mentioned before. Since almost all systems allow
  81. >the program I described above to work correctly, and it is manifestly
  82. >safe programming evenif the check is not present, I think it would
  83. >be a better choice for Linux not to do this extra check.
  84.  
  85. It's certainly *possible* for a C implementation to do full and rigorous
  86. bounds checking, even if it's rare.
  87.  
  88. I disagree; I believe implementations must be *especially* zealous about
  89. catching and crashing common mistakes.  I do not believe conceptually
  90. invalid code should be allowed to run, if there's any way to test for it.
  91.  
  92. I have only once in my life seen a compiler cause
  93.     i = ++i;
  94. to do anything but increment i.  This doesn't mean that compiler was wrong,
  95. in *any* way.  The code is devoid of meaning, and it's merely bad luck that
  96. so many implementations don't catch it.
  97.  
  98. I don't think I agree with the claim that it's manifestly safe.  An
  99. unexpected hard error could cause the disk to spew more data than you
  100. just proved it had, and you should *NEVER* give a syscall license
  101. to write past the space you want it to work with.
  102.  
  103. -s
  104. -- 
  105. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  106. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  107. FUCK the communications decency act.  Goddamned government.  [literally.]
  108. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  109.